Xcode “Targets” with multiple build configurations
How to create multiple applications that differentiate and share parts of the source code
Why do I need this?
A typical scenario for this situation is when you need to build one version of your app for iPhone and another specific version for iPad, probably you will need to share some part of your code and customize others things such as screen layout or some presentation behaviors. Another situation could be a big company that has some independent business units and desires to build just one app for these companies, we could suppose that some business rules can be different for each business unit.
How can I achieve this goal?
In the Xcode development universe we have a thing called Target, a brief description from Apple says:
A target specifies a product to build and contains the instructions for building the product from a set of files in a project or workspace.
To simplify the subject, by default when you create a new project, a Target is created into your project. If you want, you can rename or duplicate it. You may ask why do I need to duplicate one instead of creating a new one. The explanation is that associated with a Target, there are many default configurations, in this case when you duplicate a Target, you are making a clone of it. After that, you can change bundle identifier, deployment info, display name, app icons source, and so on. When you demand to run the project, you need to specify in which Target it must be done.
So, another powerful thing that a Target provides is the possibility to create a resource with the same name for each Target you have. Notice in the picture above, the project has two files declaring a class called Product, in a normal situation it will produce a compilation error, but using Target, you can assign each file to a specific Target. Look at the image below, you select the file and define the Target.
Another way to assign the Target is when you are creating a new resource, observe in the image below:
Look out! A common mistake
When you are working with Target it is very common to create a resource and forget to assign more than one Target, later when you try to compile, you get an error saying that that resource does not exist, so you look in the source code tree and file is there, but it is not been included in the selected target, believe me, I already spent some minutes trying to understand what was wrong.
A source code sample is worth a thousand words
To make it easier, I developed a simple sample application that uses a class name Product to get a property called “whoIAm”. There are two version of class Product, one for each Target and the property output is different in each case, i.e, if you run the "ProductOne" the output will be “Product One” and if you run “ProductTwo” the output will be “Product Two”. To get the source code follow the GitHub link below:
Building your app for a specific environment, i.e, development, testing or production
Generally, in most enterprise projects we have multiple environments, and from time to time we need to compile our project to a specific environment. A typical setting that we need to change to distribute a version is the URL of backend services, we could make it manually, but it is not the better way to do this. On Xcode we can create multiple build configurations and specify any setting we need to that environment, after that when we need to change the environment, we just select in which environment we are working on.
As you can suppose, in the image above you see the screen where you can create your new build configuration, the principle is the same as mentioned on creating Targets, it will be cloned from debugging or release configuration.
As you can observe in the image above, after you create a new build configuration you can add new settings and assign in which build configuration it must be applied, in our case, we are adding a different URL for each build configuration.
Changing build configuration
To change the build configuration, you need to edit the current scheme that you are using.
After that, you can select in which build configuration the build process must be done.
Getting the user-defined settings on your code
You must be asking yourself, how do I get this setting in code? We need to create a mechanism to recovery this data, and it is through Info.plist file. But wait, we are going to put there just a variable reference as you can see on the image below:
As you can see we are using the same reference “$(ENDPOINT_URL)” as typed on the user-defined section at build settings. Now, we need to load the dictionary and recovery the URL as you can see in the code below, during the build process the Xcode will replace the reference variable with URL specified on that build configuration, very elegant, don’t you think?
The complete sample using these techniques is on GitHub link below as already mentioned before. I hope it helps you understand better these concepts and if you have any question, improvement or suggestion, please feel free to contact me! See you next time.